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Sir: 

In accordance with the provisions of 37 C.F.R. § 41.41, Appellants respectfully submit 
this Reply Brief in response to the Examiner's Answer dated October 25, 2006. Entry of this 
Reply Brief is respectfully requested. 
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STATUS OF CLAIMS 

Claims 1-7, 9 and 1 1-20 are all of the claims pending in this application. 
All of claims 1-7, 9 and 1 1-20 stand rejected under 35 U.S.C. 103 as unpatentable over 
Boivie (U.S. Patent 6,502,140). 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The sole ground of rejection to be reviewed on appeal is whether or not claims 1-7. 9 and 
1 1-20 are unpatentable over Boivie. 
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ARGUMENT 

In this Reply Brief, Appellants wish to address certain points as raised in the Examiner's 
Answer, mailed on October 25, 2006. 

Boivie discusses as background the addressing/routing technique whereby only the final 
destination address is included in the header. This is described, for example, at lines 23-30 of 
column 1 . A disadvantage of this technique is that, since the header does not include any 
intermediate node information telling how to get to the final destination, each router along the 
way has to maintain a routing table of the intermediate nodes. The router can then forward the 
packet to the next intermediate node, and so forth up to the final destination. Boivie considers it 
a disadvantage that the routers have to store so much routing information, and deals with this 
problem by using a header which contains all of the routing information so that the router does 
not have to. So the concept of Boivie is to increase the amount of address information in the 
header, not decrease it. 

So the solution provided by Boivie and that provided by the present invention are similar 
in that all of the required routing information is stored in the header. But Boivie does not at any 
time suggest a concern about the size of the header, and therefore does not suggest anywhere that 
the address information in the header should be compressed in some way. On the other hand, the 
size of the header is the primary concern of the present inventors, and the present invention is all 
about how to decrease the size of the header that can still include all of the routing information. 

At the top of page 7 of the Examiner's Answer, the examiner disagrees, arguing that 
Boivie teaches "folding" of the routes, where the addresses R1R2C and R1R2D are 
combined/compressed into one address R1R2(CD) in step 2 of the disclosed process, the 
examiner directing attention to lines 30-55 of column 4. But the examiner has misread this 
passage, misunderstood Boivie, and recast Boivie to something like the present invention based 
on hindsight after reviewing the present application. 

What has happened is that the examiner is confusing IP addresses with node names. In 
Boivie, the letters A, B, C, D, E, F, G, H, I designate nodes, as shown in Fig. 1. When node A 



REPLY BRIEF UNDER 37 C.F.R. § 41.41 
U.S. Appln. No. 09/422,347 



Atty. Docket: Q56325 



has to send a packet to node H, the sequence of intermediate nodes the packet will travel is A, 
Rl , R2, C, F, H. A packet sent from node A to node G will follow the path A, Rl , R2, C, G. 
But these are paths, not IP addresses. For example, a packet to be sent from node D to node H 
would follow the path D, R2, C, F, H. If this were the IP address, it would mean that the node H 
has one IP address for a packet sent from node A and a different IP address for a packet sent 
from node D, which is of course not the case. 

So when Boivie talks about "folding" the routes, he is doing just that, i.e., folding routes, 
not compressing addresses. Note that in the entire discussion of folding at lines 30-55 of column 
5, Boivie never once uses the word "address". And the folded end product is not an address but 
a "list." Boivie's list Rl (B R2 (CD)) at line 58 of column 5 will be the complete four-octet IP 
address of node Rl so that the packet will be forwarded to Rl, followed by the complete four- 
octet IP addresses of each of nodes B and R2 so that the packet can be forwarded to B and R2, 
followed by the complete four-octet IP addresses of nodes C and D so that the packet arriving at 
R2 can be forwarded to each of nodes C and D. 

If one were to generate a "folded" routing list corresponding to Fig. 1 of the present 
application, there would be a first address of node Rl to get the packet to that node, a next 
address of nodes R2 and R3 to get the packet to those nodes, and next addresses for each of 
nodes Dl, D2 and D3, with the resulting "folded" routing list looking like: Rl (R2 (Dl D2) R3 
(D3)). This folded routing list would then "unfold" as the packet worked its way along the tree. 
But each address for Rl, R2, Dl, D2, R3 and D3 would be a complete four-octet IP address. 
Boivie does not suggest anything else. That would mean 24 octets to express this folded routing 
list. The present invention, on the other hand, as described in the specification and in the Appeal 
Brief, would express the entire address list in only 8 octets. 

So the "folded" routing list differs from a compressed address list in that (1) folding is 
not synonymous with compressing and (2) a routing list is not an address list. The examiner has 
glossed over these distinctions, and since there is no mention of either compression or addresses 
in Boivie, the rejection can only be based on hindsight. 
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At the bottom of page 7 of the Examiner's Answer, the examiner acknowledges 
appellants' argument as to the length of the header in Boivie being much longer than in the 
present invention, but dismisses this as irrelevant in that appealed claim 1 is directed to 
compressing a list of addresses, not claiming compression of the addresses themselves. This is 
incorrect. Claim 1 recites the detecting of a common prefix in at least two addresses, the 
generation of a suffix list which represents the non-identical portions of the addresses that have 
the common prefix, and the adding of the suffix list to the common prefix to create a compound 
destination address consisting of compressed final destination addresses. 

At pages 8 and 9 of the Examiner' Answer, the examiner deals with the problem of 
Boivie not compressing addresses by discussing "source addressing," "predefined routes" and 
"unknown routes." The examiner is essentially arguing that the node list in Boivie is the address, 
so compressing the node list is compressing an address list. But this appears to be an after-the- 
fact rationalization in an effort to support a rejection based on hindsight. Boivie simply does not 
discuss how the addresses of any of the nodes are expressed. But it is clear that a single node 
will not have multiple different addresses depending on where the packet is coming from, as 
discussed above. As reflected in Fig. 1 of the present application, the address of, e.g., node D2 is 
A.B.C.E. In a "folded" routing list as taught by Boivie, if applied to Fig. 1 of the present 
application, the address of node D2 would be represented as A.B.C.E. There is no suggestion of 
trying to compress the addresses in Boivie. 

Boivie seeks to eliminate the need for a router to store a routing table by including all of 
the intermediate nodes (i.e., the route) in the header. The present invention does not eliminate 
the routing table. Note, e.g., the discussion from line 16 of page 5 through line 3 of page 6 of the 
present application as originally filed, which describes how the compressed list of final 
destination addresses according to the present invention can be used to more efficiently access 
the routing table. The examiner has throughout confused destination addresses with routing 
information. In the "folded" routing list Rl (R2 (Dl D2) R3 (D3)) discussed above, the first stop 
on the route is node Rl . To get to Rl, the system must have an address for Rl . That address 
will be a four-octet IP address which is the case for any network node. The addresses needed for 
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the other nodes R2, etc., will also be four-octet IP addresses, or at least full addresses of 
whatever addressing scheme is being used. Boivie suggests nothing different, and certainly says 
nothing about address compression. IN fact, Boivie does not even deal with addresses, sinly 
node names to include on a routing list. The examiner is either failing to understand this 
difference, or he is reading into Boivie a teaching which simply is not there, and in either case 
the rejection is not well-taken. 

CONCLUSION 

The present invention is directed to a technique of address list compression that may well 
share some similar concepts with what is taught by Boivie. But the technique is different, there 
is nothing in the art to have suggested the use of the claimed technique, and the results achieved 
by the invention are much different from what would result in Boivie, .e.g., 8 octets in the 
present invention v. 24 octets in Boivie, in the example explained above. Accordingly, it is 
submitted that the examiner has not presented a prima facie case of obviousness, and the 
rejections should be reversed. 

Respectfully submitted, 
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